Loop Engineering
https://addyosmani.com/blog/loop-engineering/
Addy OsmaniによるLoop Engineeringについての記事
Loop Engineeringとは
エージェントにプロンプトを送る人間を自分自身から置き換えることである
代わりにプロンプトを送るシステムを設計する
ループとは目的を定義しAIが完了まで反復する再帰的なゴールと捉えられる
コーディングエージェントとの今後の働き方になりうると著者は考える
ただしまだ初期段階でありトークンコストには十分注意が必要
プロンプティングからループ設計へ
Peter Steinbergerはエージェントに直接プロンプトするのではなくプロンプトを行うループを設計すべきだと述べた
AnthropicのClaude Code責任者Boris ChernyはもうClaudeに直接プロンプトせず、プロンプトを行うループを動かしており自分の仕事はループを書くことだと述べた
従来は良いプロンプトと十分なコンテキストを書いて1ターンずつ対話していた
これからは作業を見つけ・割り振り・チェックし・記録し・次を決める小さなシステムを作り、エージェントを突く役割をそのシステムに任せる
agent harness engineeringの一階層上に位置する
ハーネスがタイマーで動き、小さなヘルパーを生成し、自分自身に入力を与える
ツールではなく設計の問題になった
1年前はループを作るなら大量のbashを書いて永久にメンテする必要があった
現在は各プロダクトに部品が同梱されている
SteinbergerのリストはCodexアプリにほぼ一致し、Claude Codeにもほぼ一致する
形が同じと気づけばどのツールかの議論は不要になり、どちらでも動くループを設計すればよい
ループに必要な5つの部品+記憶
1. Automations スケジュールで起動し発見とトリアージを自動で行う
2. Worktree 並行作業するエージェント同士が衝突しないようにする
3. Skills エージェントが推測するしかないプロジェクト知識を書き留める
4. プラグイン・コネクタ 既存ツールにエージェントを接続する
5. サブエージェント 一方が案を出し別の一方がチェックする
6番目が記憶(メモリ)
markdownファイルやLinearボードなど単一の会話の外に存在し、完了済みと次を保持するもの
モデルは実行間ですべて忘れるため記憶はコンテキストではなくディスク上に置く必要がある
long-running agentsで詳述した手法
両プロダクトとも現在5つすべてを備える
Automations(ループの心拍)
ループを一度きりの実行ではなく実際のループにするもの
CodexアプリではAutomationsタブでプロジェクト・プロンプト・頻度・実行環境を指定
発見があった実行はTriageインボックスへ、何もない実行は自動でアーカイブ
OpenAIは日次issueトリアージ・CI失敗の要約・コミットブリーフィング・バグ探しに内部利用
AutomationはSkillを呼べるので巨大な指示文を貼らず$skill-nameで起動できる
Claude Codeはスケジューリングとフックで同じことを実現
/loopでインターバル実行、cronタスク、エージェントライフサイクルでのシェルコマンド発火
GitHub Actionsに載せればラップトップを閉じても動き続ける
セッション内プリミティブ
/loopはカデンスで再実行
/goalは書いた条件が真になるまで継続し、毎ターン後に別の小モデルが完了判定する
コードを書いたエージェントが採点しない構造
Codexにも同名の/goalがあり検証可能な停止条件まで継続
Worktree(並行を混沌にしない)
複数エージェントを動かすとファイル衝突が失敗要因になる
git worktreeは同じリポジトリ履歴を共有しつつ別ブランチの独立作業ディレクトリを作る
一方のエージェントの編集が他方のチェックアウトに触れられない
Codexはworktreeサポートを内蔵
Claude Codeはgit worktree・--worktreeフラグ・サブエージェントへのisolation: worktree設定で同じ分離を提供
orchestration taxで論じたとおり機械的衝突は消えるが人間のレビュー帯域が上限になる
Skills(毎回プロジェクト説明をやめる)
毎セッション同じプロジェクト文脈を金魚のように再説明するのをやめる手段
両ツールともSKILL.mdを含むフォルダという同じ形式を使う(任意でスクリプト・参照・アセットを含む)
Codexは$や/skillsでの呼び出し、またはタスクが説明に一致すれば自動実行
退屈で的確な説明文が巧妙なものに勝る理由
intent debtで論じたとおりエージェントは毎回ゼロから始まり意図の穴を自信ありげな推測で埋める
Skillは外部に書き留めた意図であり、規約・ビルド手順・過去の事故の教訓を一度書けば毎回読まれる
Skillは著作フォーマットでありプラグインは配布手段
複数リポジトリで共有・束ねる場合はプラグインとしてパッケージする
プラグインとコネクタ(実ツールに触れる)
ファイルシステムしか見えないループは小さなループ
コネクタ(MCP上に構築)はエージェントにissueトラッカー読取・データベース照会・ステージングAPI・Slack投稿を可能にする
CodexもClaude CodeもMCPを話すので一方用コネクタは他方でも大抵動く
プラグインはコネクタとSkillを束ねチームメイトが一括導入できる
「修正案はこれ」と言うだけのエージェントと、PRを開きチケットを紐付けCIがグリーンになったらチャンネルに通知するループの違い
サブエージェント(作る者と確認する者を分ける)
ループで最も有用な構造は書く者とチェックする者を分けること
コードを書いたモデルは自分の宿題を甘く採点しすぎる
異なる指示・時に異なるモデルの第2エージェントが見逃しを捕える
Codexは要求時のみサブエージェントを生成し並行実行して結果を1つに統合
.codex/agents/にTOMLで定義(名前・説明・指示・任意のモデルと推論努力)
Claude Codeは.claude/agents/のサブエージェントとエージェントチームで同じことを行う
典型分担は探索・実装・仕様に対する検証の3つ
code agent orchestraやadversarial code reviewで既に論じた主張
ループは見ていない間に動くので、信頼できる検証者だけが立ち去れる理由になる
サブエージェントは各自モデルとツールを使うためトークンを多く消費する
Claude Codeの/goalが裏でやっていることと本質的に同じ
1つのループの形
毎朝automationがリポジトリで実行される
プロンプトがトリアージSkillを呼び前日のCI失敗・オープンissue・最近のコミットを読み、findingをmarkdownやLinearに書く
やる価値のあるfindingごとに独立worktreeを開きサブエージェントが修正案を作成
第2サブエージェントがプロジェクトSkillと既存テストに対し案をレビュー
コネクタがPRを開きチケットを更新
ループが扱えないものはトリアージインボックスへ
状態ファイルが全体の背骨で、試したこと・通ったこと・未解決を記憶し翌朝続きから始まる
一度設計しただけで各ステップをプロンプトしていない点が要点
ループがやってくれないこと
ループは仕事を変えるが人間を消さない、3つの問題はループが良くなるほど鋭くなる
検証は依然として人間の責任
無人で動くループは無人でミスを犯すループでもある
「完了」は主張であって証明ではない
自分が動作確認したコードを出荷するのが仕事(code review in the age of AI)
理解は放置すれば腐る
ループが速くコードを書くほど、存在するものと自分が把握するものの差が広がる
これがcomprehension debtで、滑らかなループは差を速く広げる
快適な姿勢が危険
ループが自走すると意見を持つのをやめ与えられたものを受け取りたくなる(cognitive surrender)
判断を持って設計すれば治療、思考回避のために設計すれば促進剤、同じ行動で逆の結果
結論: ループを作れ、エンジニアであり続けろ
仕事の進化のプレビューだが、自分でコードをレビューせず自動ループに完全依存すれば品質は落ちる
ループを設定しつつ直接プロンプトするのも有効、バランスが重要
同じループでも人によって正反対の結果になる
深く理解した作業で速く動くために使うか、理解を避けるために使うか
ループはその違いを知らない、人間が知っている
これがループ設計をプロンプトエンジニアリングより難しくする理由
Boris Chernyの論点は仕事が楽になったではなく、レバレッジポイントが移ったこと